PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.55

Text File | 1988-06-15 | 32.2 KB | 683 lines | [TEXT/ttxt]

 1-May-88 11:19:57-PDT,33654;000000000001
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Sun, 1 May 88 11:18:32 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa26213; 1 May 88 13:35 EDT
Received: from relay.cs.net by RELAY.CS.NET id aa00924; 1 May 88 13:30 EDT
Received: from sdr.slb.com by RELAY.CS.NET id aa00911; 1 May 88 13:27 EDT
Date: Sun, 1 May 88 13:23 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #55
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Sun  1 May 88 13:23:40-EDT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #55
To: Usenet-List: ;
Message-ID: <578510620.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Friday, April 29, 1988         Volume 4 : Issue 55

Today's Topics:
     Mac/Mainframe Email Systems

----------------------------------------------------------------------

From: [e-mail] (Alex Heatley)
Subject: Mac/Mainframe Email Systems
Date: 25 Apr 88 23:30:16 GMT
Organization: Computing Serv. Ctr, Victoria Uni., Wellington, New Zealand


        Electronic Mail Between Mac and Mainframe Mail System

               WARNING - LONG POSTING.

Well, it seems that I have produced a considerable amount of discussion
from what I thought to be a trivial question. I've collected all the
replies I've recieved and sumarised them below. I've also added my
comments where appropiate and at the end I'll talk about what I was
after when I asked about whether there were any mail systems that did
what I wanted. My thanks to all those who replied and posted. With luck
we might all get a mail system out of this.

First off are the names and addresses of all the people interested in
such a system. I'm including these so that they can be contacted if
anyone comes up with something.

    Mark Meredith (Unisys, Salt Lake City, Ut)
    {ihnp4, hpda, uplherc}!sp7040!mjm
    [e-mail]
    801-594-6319

    JOACHIM LINDENBERG <[e-mail]>
    Joachim Lindenberg, University of Karlsruhe
    Federal Republic of Germany - West Germany.

    Michael Helm (Arpanet: [e-mail])
    LBL          ( uunet!Lbl.gov!M_Helm  has been known to work...)

Now for the postings and email that had things of interest..

>From: [e-mail] (Edward J Cetron)
Date: 20 Apr 88 04:23:14 GMT Reply-To: [e-mail] (Edward J
Cetron) Organization: Center for Engineering Design, Univ of Utah

I think the first question to answer is the physical distribution
method.  If every Mac is directly connected to a VMS/UNIX box, I know of
at least one (maybe more) Public Domain packages which will work. I also
know of several Appletalk-only Mac to Mac systems (Intermail, Inbox,
TOPSsomething, etc).

            What I DON'T see is a mechanism which:

    1. can be used Mac to Mac via localtalk transport.

    2. can ALSO be used Mac to ??? via localtalk to ethertalk.

My suggestion (and yes it is just MY suggestion based on our facilities
preferences after trying lots of mailers on the Macs AND the two flavors
of vaxen):

1. use 'standard' SMTP as the transport mechanism from ??? mainframe to
a centralized Mac. Currently, Mac-PMDF seems to be the most versatile
package for this.  What needs to be added is the transport via ethernet
to localtalk for those sites, serial line support is already there.

2. use Intermail as the Mac to Mac package.

3. write the code and hooks to gateway the mail from Mac-PMDF to
Intermail. This will likely be the hardest part. Also, if a very clean
job is done here, many other Mac-Mac mailers could be added here.

Well, that's my two cents worth....now if only I could find to time to
check how reasonable the above is.... maybe Microsoft (who know owns
Intermail) would be interested?

-ed

[Alex comments: This sounds interesting. My major objection is the
implied use of a Mac as a server. Ideally, the server should reside on
the Mainframe, if possible, in much the same way that using the CAP
software, you can have an AppleServe server residing on a UN*X box. My
reason for wanting to do it this way is that Macs are expensive and if
you have a CPU running the Gateway, it might as well run on the
mainframe.

I'd also note that the reason while I use the term mainframe is that our
main e-mail hub is actually a IBM 4381 complete with custom mailer and
user interface. It works very well and we would like to expand it
through to the Macs. From our point of view, this can be done by using a
combination of a UN*X box and a Multigate box, gatewaying from the IBM
to the UNIX box, then out onto the LocalTalk network via the Multigate
box.

What I had hoped would happen when I posted, was that someone such as
THINK would say "Hi, here is the protocol for our InBox server. You can
use this to write your own server sitting on whatever CPU you like."
That didn't happen. So what I might do is write a LocalTalk monitor and
work out their protocol myself. Do people think this is a reasonable
approach?]

>From: [e-mail]
Subject: Re: Macintosh mail systems. Date: 18 Apr 88 21:15:33 GMT
Organisation: Universitaet Karlsruhe, IRA, F.R. Germany

There has been an ongoing discussion about Macintosh mail systems in the
past days, and as David suggested, anyone should state his/her
requirements.

The following text will outline the requirements/interface that I see.
This is not intended to be a full spec, although we are thinking about
implementing it. I am a student of computer science at University of
Karlsruhe, Federal Republic of Germany, and I am involved in Macintosh
projects at that university. I am a computer consultant, too. There is
no big difference between the requirements at our university and large
companies in Germany.

1. Macintoshes are turned on and off frequently, and may be off for long
periods of time (e.g. during holidays). Mail must not be returned
UNDELIVERABLE because of that. This implies that there must be a mail
server. Because most universities and companies already use a
UNIX/VMS/other host for mail, using this host to serve Macintosh mail is
the most likely solution. This does not imply however, that s/he is
allowed to login to that host.

There are a number of possibilities, how the Macintosh front-end might
communicate to the host, two of them are MacWorkstation and an AppleTalk
service (based on CAP, AlisaTalk, ..), others might be SMTP, NNTP which
I am not familar with. The protocol may be proprietary, because it is
only used to communicate to the mail server, not to the world.

Of course if Apple released their specification of the AppleTalk
Messaging Protocol (Larry Taylor of Apple talked about it at EUC
Heidelberg, April 8th, 1988), I'd go with that, if it suits all needs.

2. There must be a unified interface to mail and news, like the
integration present on unix hosts. I don't want to use a mac application
to read/send mail and another one to read/post news - or even worse,
login on to (different) host to do that. The application should also
support digests (whether received by mail or news), and interpret reply
or followup sensibly, i.e., reply to the originator of the message, not
to the sender of the digest, mail followups to the origin of the digest.

[Alex again: I think that reading/sending news is making the requirement
needlessly complex. I use rn for reading usenet and mail for sending
mail, I don't see why we have to have both a newsreader and a email
facility in the same package. I think that having the facility to read
news should come later as a different project/application]

3. Unlike the present mail applications, INBOX and INTERMAIL one cannot
assume that all possible recipients are known to the mail server. This
could be reasonable for one university or company, but not with the
internet behind. Of course, if your site already has a nameserver, the
mail application should be able to lookup local mail addresses by name.

[Alex: I'm not sure this makes sense, I imagined that we would have
addresses which flagged whether or not they were local or needed to be
passed to the mail server hub. For example, if I want to speak to Bill
on another Mac connected to my LocalTalk then I send email to Bill. If I
want to talk to Bill at MIT I go Bill@MIT (or whatever the correct
RFC822 address form is), the Mac server looks at the address, realises
that it doesn't know about MIT and throws it at the email server.]

4. One cannot assume that anybody is going to use a Macintosh to read
her/his mail. This has two consequences:

First, if files are to be transferred - and there is definitely a need
to include support for that - they must be included in a way that allows
them to be extracted manually and processed by some other tool. A simple
but sufficient solution is to include them binhexed, each preceeded by a
line standard mail will read this just as he always did and fire up
binhex or stuffit. A user using the mac mail will read a message that
this mail contains files, and choose extract from the file menu...

Even if I am using a mac to read mail, I may want to process/archive
files on the host. Someone might have mailed me a shar archive for use
on the (unix)host, or I may use unxbin on a unix computer and store the
files directly to AUFS volumes (that's how I install new stuff).

Second, there must be a character set conversion included. If you are
only going to mail in English, this is not required. If however, you
receive mail from any country, this is important. Imagine German
umlauted characters.  Of course these characters are included in the
Macintosh character set.  But they aren't ASCII. If I know that the
recipient of the mail is using a mac too, and that the mailers in
between don't discard characters with the eigth bit on, I may send the
character unchanged, otherwise it has to be mapped to the closest ASCII
equivalent, possibly combined by several characters. Alternatively, some
other German user is using the German version of the ISO character set.
This is ASCII with the special characters [\]{\}~ replaced by German
characters. I want to tell my Macintosh that any mail received from this
user is to be interpreted using that character set. Another example:
VAX/VMS supports multinational characters using an ASCII extension,
proprietary to DEC.

The point is, that there must be a possibility to convert both incoming
and outgoing characters, depending upon the sender/receiver and/or
system defaults. I emphasized this point, because this is crucial to our
environment - you won't sell your mail program in Germany, if the user
gets beeps or garbage typing umlauted characters. Of course this is a
marketing decision.

Most of the points above are technically, not related to the user
interface. The following highlite some of the user related aspects.

5. It should include an editor. It does however not need to be a full
blown word processor. If you want to pass your new novel to another mac
user, include the document as an attached file. Anything within the
range of TeachText and MPW Shell is possible. No styles or justification
is required (imagine an IBM PC user, reading your letter on his
monochrome card), but font and size should be user selectable. Word wrap
should be automatic, based on charcter count, not on the window size.

[Alex: Because this thing has to send mail to people using other
machines, it must insert a <CR><LF> at the end of a line so that people,
like myself who read their mail on misbegotten IBM systems don't end up
with messages that go off the end of the screen]

The program should be able to manage arbitrarily large files. This may
however be limited to viewing/archiving them, not editing. The largest
mail I received was 2 MB and consisted of a uuencoded tar archive. Of
course this mail was to be decoded by unix tools, but you don't want
your mac to crash because of a large mail.

6. It has become a habit to comment on text by preceeding it with some
special character like > and inserting new text. While this is not the
only way to point out what you are going to reply to, and especially the
mac could provide a more graphic feedback (at least different fonts),
this technique is common sense. If the user chooses a function like
reply, the macintosh mail program should copy selected text
(discontinous selections should be supported) to a new window and mark
it as comment.

[Alex: This feature is something that can be added later. It should not
necessarily be part of the initial design]

7. The program must provide for a list of name aliases. This should be
entirely transparent to the rest of the program. I.e. there should be no
special dedicated menus, but editing the list should be allowed whenever
a mail address is required and selected from the list. Selection should
be possible by both scrolling/clicking or typing as in standard file.
New aliases should be created automatically if you reply to mail. There
must be an option to delete no longer used names.

8. While incoming mail should be presented in separate windows
automatically, this may not be appropriate for news. A scrolling list of
items that can individually or collectively be opened or discarded comes
to my mind. There should be either no (prefered) or a very large limit
to the number of open windows - aren't you bothered by the finder's
limit of 12 windows?

[Alex: I don't think that having three mail messages up at the same time
is an important feature]

9. There must be an automatic archive feature. I want any incoming mail
to be saved automatically, say in a folder named after the sender and
with the filename taken from the subject. There should be a flag
associated with each newsgroup, whether it should be archived (local or
remotely) or not, and this flag should be independent from whether I
want to read it or not - I don't read binaries.

[Alex: I would prefer to be able to save mail messages, with the default
of them being destroyed (user switchable)]

There should be an option that asks me where to put the file and when it
should be resubmitted. I consider this to be an important feature if
mail is going to be used in your administration. This will also provide
a simple reminders utility, although a real appointment calendar is more
superior.

[Alex: again the requirement that the application also serve as a news
reader and manipulator is needlessly complicating the design.]

10. There should be an INIT that checks for mail on startup (this could
be a RDEV that selects among several mail hosts). There should also be a
possibility for the mail host to tell you about new mail arriving during
your macintosh work. This could be done using the broadcast mechanism I
published in the past (you can get it free, send mail to
[e-mail], I'll mail it to you).

[Alex: To me, the ability to notify a user that mail has arrived, while
they are using their Mac is essential. Furthermore it should not rely on
applications running in the background under multifinder.]

Joachim Lindenberg, University of Karlsruhe Federal Republic of Germany
- West Germany.


>From: [e-mail]
Subject: Mac Mail - more thoughts Date: 21 Apr 88 19:41:08 GMT

A lot of messages came in on this subject, many requesting any
information that I received but some providing information on their own
needs and enironments. Most of the latter were cross posted to
info-appletalk or comp.protocols.appletalk and thus you've already seen
them.

The following is fairly general and is mostly intended to spark more
comments and input. Please bear this in mind as you read it.  Also bear
in mind that I'm writing this at 11PM .... I'm waiting on more
information from several places but didn't want to hold everything up
'til next week.

Several mail products for the Macintosh exist, most notably CE
Software's QuickMail which is currently in beta test. It will provide
hooks for external mail interfaces. Byron Han described it earlier in
this forum and I have nothing to add to his comments at this point.
Stanford will have Mac/MH in the near future for universities with
SU-Mac/UP licenses. Kinetics cannot comment on future marketing policy
for the Stanford system. It would surprise me if Apple was not working
on something as well but as I am not a developer at the moment they
would not provide me with any information. The best thing to do may be
to sit back and wait. If you're not the waiting type, read on ...

One thing should be clarified: I am not working on this as a BBN
employee at the moment and thus have little resources of my own to do
anything but serve as a clearinghouse of information and to test,
define, and haggle on my own time. Don't expect me to sit down and start
writing anything just yet ....

I've used many different mail systems, from Berkeley's BSD mail to
several version of MH (one of which I am using now) to front ends to
mail written for Gosling's Emacs to some abomination on a TOPS-20 to
CMU's Andrew Message system. The latter was by far the most useful,
which is not terribly surprising as it ran under Andrew and made
extensive use of the window system. Unfortunately, it is also deeply
tied to the entire Andrew environment as is the MacMessages currently
under development at CMU unless things have changed drastically since I
left.

The Macintosh obviously provides a window manager of sufficient power to
support an ellegant user interface. With a hard disk there is only one
good reason for the Mac not to be a mail client rather than just a
interface (via a terminal emulator if need be) into a mail system
running on a timesharing host. The one good reason that I'm aware of is
that the Macintosh is frequently not present to receive mail. The Mac on
my desk is usually up and running but what about the Mac at home? Which
actually leads to a second good reason: I've two Macs that I read mail
from and if mail was delivered to one then the mail would be unavailable
from the other Mac. [RFC 993 (PCMAIL) addresses these problems and is
worth reading.]

These problems indicate a need for a mail server running on some central
host. I believe the majority of us operate in an environment that
includes some UNIX machine thus providing a possible common server
machine. Yet I am aware of at least two groups using mostly Macs and
Lisp machines of various flavours who would be unable to access a UNIX
server and would need the ability for the Mac to send a legal mail
message to both an Internet site across the country and to the Mac
across the lab. I tend to fit into the latter group with the added
complication that my Mac at home isn't even sitting on a network.
Perhaps I just lose out on that situation but I suspect that many others
have a Mac at home and would appreciate the ability to compose, send,
and receive mail at home using a serial line. This would fit well into
the server model but I do not see a clean way to fit it into the model
of a Mac as its own host.

The other obvious problem is how to reliably get the mail message from
the Mac, in either model, into the normal distribution system for the
environment. Once again, most of us are running TCP/IP but there are
still exceptions to this. CMU is using CUI/SNAP on a TCP/IP network,
Dartmouth is using KSP on an Appletalk network (Kevin will correct me if
I am wrong again ....), PCMAIL uses DMSP on top of USP (Unified Stream
Protocol), Stanford Network Services' Mac/MH uses SMTP and MHPOP on a
TCP/IP network, and a UMich system uses MVP (Mail View Protocol) on a
TCP/IP network (I presume). A common system is going to need a common
mail protocol. Done correctly, the stream protocol can be left up to the
user. (From what I understand of PCMAIL it relies heavily on features in
USP.)

If a common system is to be developed then two things must happen: 1) We
must decide on a model or figure out some way to combine the two and b)
given a server model we must decide on a transport mechanism.  Or on
several of them. Once you have the model and the transport done then you
should be able to customize your user interface to suit.  If your low
level routines provide the ability to deliver a message to a specific
address, to file a message in a folder, to accept an incoming message,
to maintain mailing lists, and a few other basic services then you're
most of the way there. I am *not* implying that the user interface issue
is simple, but that it is a distinct problem. With the lower level
services available you can drag an icon of your mail message into a
mailbox or pull down a menu and select "Deliver".  Such decisions are
certain to start a religious war.

One specific idea that came up was the question of mail notification.
It would be desireable to have a task listening for a message indicating
that new mail arrived. This is a necessity if the Mac is to be a mail
host, obviously. If the mail is actually delivered to a server somewhere
for collection when the user so desires he still would like to know that
it is there without starting up a full mail session.

That is the lot of it for the moment. Please comment, submit ideas, et
al. I've nothing available for anyone to test and nothing for anyone to
commit development resources to. Development, I suspect, will be up to
those interested in having a major say in what such a system looks like.
If commerical products are satisfactory, then we're all set ....  If
this is getting beyond the scope of info-appletalk we might think about
setting up a different mailing list for it. Does anyone mind seeing all
this mail traffic going around?

[Alex: Again, I think that making the problem too general may retard the
design. Most of us have UN*X boxes speaking TCP/IP, some of us have
K-boxes or Multigate boxes that act as bridges between Ethernet and
LocalTalk. Perhaps our mail application should be designed around these
common factors first. Then it can be adapted to other systems.]

-David Kovar
 [e-mail]

Date: Wed, 13 Apr 88 16:17:49 PDT
>From: 98820000 <[e-mail]>

I saw your posting and was wondering what the responses were.

We will be trying to get something like that up and running from our Sun
and some VAXes here.  We also would like to make it possible to access
the spelling checker and person locater we have as well.

                                                        John Rocchio

[e-mail]

[e-mail]

[Alex: If you want to add additional features such as you describe, you
have two courses of action, 1. provide the facility to log into a target
machine. 2. perhaps use NFS (I'm just guessing here) to access the files
you want from a specialist application.]

Date: Fri, 15 Apr 88 12:58:35 MET DST
>From: [e-mail]
Subject: Re: E-mail Mac/Mainframe To: [e-mail] Organization:
University of Karlsruhe, W.-Germany

Yes , it is exactly whtat we need right now. A facility to read and post
News from the Macs and an interface to the mainframe mail systems.

I do not know of any existing system of that kind; at Karlsruhe
University we have two or three people who are almost motivated to do
such a thing.  For mail we must write a server for the Unix-host. For
the Macs we need TCP/IP software and a nice interface. A protocol for
News exists : NNTP, for mail we can perhaps use SMTP or invent something
similar to NNTP.

Problems are: 1) identification of the Mac-User and 2) security on the
AppleTalk because everybody can tap on AppleTalk and listen to passwords
etc.

Please keep me informed on any progress you hear of.

Thanks, tom.

[Alex: we are not terribly worried about security issues, UUCP is also
unsecure, that does not prevent people from using it. To solve this
problem we need to look at a complete solution that makes a message I
send to you from my Mac in New Zealand (Aotearoa) to your Mac in Germany
secure, every step of the way. If that is not our goal, then we need not
worry so much about security.]

Date: Thu, 14 Apr 88 13:20:00 PDT Sorry I don't have anything useful to
tell you (some Real Soon Nows, but...) Date: 14 Apr 1988 1407-PST
(Thursday)
>From: Raman Khanna <[e-mail]>
Subject: Re: E-mail Mac/Mainframe

At Stanford we have developed a mail system for Macs that uses regular
Arpanet mail.  Incoming mail is stored in a Mail Box on a Unix machine
and users can retrieve it at their convenience.  Outgoing mail is sent
directly from individual Macs using SMTP.  We are currently working on a
user manual for the package.  I expect that we will be able to start
shipping the package in a month or so.  This package is available to any
university (in US or abroad) for free (We charge $100 to recover copying
and distribution costs).

In case you are interested, please send a message to:

              [e-mail]

raman khanna Networking and Communication Systems Stanford University

[Alex: This system meets my requirements, except for incoming mail. I
can't see the difference in using this system and having Mac users log
onto a mainframe to receive and *send* their mail. The whole point of
having a mail system on the Mac is to avoid having the Mac users learn
another user interface.]

Date: Thu, 14 Apr 88 13:45:35 -0800
>From: [e-mail]
Subject: Mail system for Macs

Alex:

Here at Stanford, we are putting the finishing touches on a package
called Mac/MH, which might be capable of meeting your needs.  Mac/MH
allows a Mac to retrieve mail from a Post Office server, using the
MH/POP (Post Office Protocol) that is supplied with the standard MH
distribution from UC Irvine (MH is a mail front end for Unix systems, if
you're not familiar with it). This is all designed to work on a
LocalTalk connected to an Ethernet via a Kinetics FastPath.  It can also
work on a Mac II directly on an Ethernet.  The POP server currently runs
only on BSD-type Unix systems.

The Mac user has a mailbox account on the server (which is *not* a
regular login-able account), to which his/her correspondents direct
mail, using any of the Unix methods (we use IP/SMTP mostly here).  The
Mac users fetches mail from the server, which shows up in an Inbox
folder.  A display similar to view-by-name shows the messages in the
Inbox (or other folders) with an icon for read/not-read, etc.

For outgoing mail, the Mac user creates a message in the Mac/MH
application, which provides To:, Subject:, etc fields automatically.
Text files can be inserted.  Outgoing mail is sent using SMTP, most
likely to a local host which can forward it to its destination.

Mac/MH doesn't do automatic notification, but it is MultiFinder aware,
so it could be left running continuously on a MultiFinder machine.

We currently license Mac/IP (which provides Telnet and FTP) to
Universities for $100 (binary only).  Mac/MH, when released, will most
likely be distributed similarly.

If you're interested, wait about a month, then send an inquiry to

        [e-mail]

Cheers,

- RL "Bob" Morgan
  Networking Systems
  Stanford University

[Alex: I could live with this package. It only fails in not
automatically notifying the user of incoming mail.]

>From: [e-mail]
Subject: Re: E-mail Mac/Mainframe

There is a little-known product family from AT&T called "Private Message
Exchange" (PMX, supposed to remind you of PBX) which may do what you
want.

PMX-TERM is a curses-based unix-based screen interface to the mail
system. PMX-PC is an xmodem-based unix-side "Message server."  On the
back end, it
        interfaces to rmail and /usr/mail/*; on the front end, it talks
to:

Access I - a blue-clone based "User Agent."  Nice windows, etc. Access
III - a Mac-based User Agent.

The interface presented by PMX-TERM, Access I, and Access III are as
similar as practical, a plus if you are operating a mixed environment
like most folks. The pmx-pc interface to the Access programs is a subset
of the (also little known) AT&T Mail common-carrier service (although
that is likely to be of limited interest to an Aussie!).  PMX-PC and
PMX-TERM have been ported to a wide variety of Unix platforms -- I
haven't a complete list handy, but certainly PDP-11, Vax, 3B(1,5,20),
Pyramid, Amdahl(UTS) are there.

I am not entirely disinterested here -- I am the author of Access III,
and I'm currently giving it an overhaul.  Although asynch-based (not
AppleTalk) both Access products run in background (the new Access III,
available 6/88, runs happily in background under MultiFinder.

If you'ld like more details let me know.

=Ned Horvath=

[Alex: Yes I would like some more details, could you post them to the
net so that others who are interested may also be informed?]

Date: Thu, 14 Apr 88 17:59:53 PDT
>From: [e-mail]
Subject: Re: E-mail Mac/Mainframe

I have often considered writing a Mac implementation of SMTP. I talked
to CE Software at Macworld SF a few months ago about the fact that they
might want to add SMTP support to their new mail product. They were not
aware of what SMTP was, but I gave them some pointers to info about it
so maybe they will add it.

In case you don't know what SMTP is, it is the protocol that sits on top
of a transport protocol (such as TCP/IP or X.25) to handle mail. Since
you have a Kinetics box and can spool LaserWriter output to lpr, I
assume you have some sort of TCP/IP. According to your map entry, your
machine is a Pyramid connected via X.25, so your mail can at least be
delivered that way. If your TCP/IP stuff does not support SMTP, you
could implement the server under X.25, but I have no idea how difficult
it would be. If either of these is true, all you would have to write is
the server for the Mac side, since the server for the UNIX side is built
into sendmail or whatever daemon handles mail via X.25. You will only
have sendmail if you have Berkeley UNIX or something similar. If you
have a SysV system, you will probably have to go the X.25 route.

If you would like to write such a server using the TCP/IP
implementation, you might want to start with the NCSA Telnet source for
the networking part, and modify it to implement the SMTP protocol as
specified in RFC 821. I don't know where you would get sample code for
X.25, but you could probably post on the net and get some. It would also
be a *very* good idea to make sure your outgoing mail messages conform
to RFC 822. If you need these RFC's, I would be glad to send them.

If none of this makes any sense, please let me know what needs
clarifying.  If this makes a lot of sense, let me know if you want to do
it. If you do, I'm sure there are a lot of organizations and
universities that would want it. Please let me know what you think of
this idea.

David Ackerman California Department of Water Resources
caldwr![e-mail]  (Internet) "It's the water, and a lot more..."
    ...!ucbvax!ucdavis!caldwr!ack  (UUCP)

         The opinions expressed above are mine, not those of the State
         of California or the California Department of Water Resources.

[Alex: This was extremely helpful. It allowed me to further define what
I was after. Which is a gateway that sits between sendmail and a Mac
mail package such as Inbox with the gateway perferably running on a
mainframe.]

Date: Fri, 15 Apr 88 18:28:43 cdt
>From: Farhad Xerxes Anklesaria <[e-mail]>
Subject: E-mail Mac/Mainframe To: [e-mail]

Greetings Alex,

Read your posting on USENET.  We have a similar system: Un*x boxes,
K-boxes, CAP.  Starting work to build something like you are describing.
 We'll keep you posted on how/what we're doing.  If you find out
anything interesting.... or a ready made solution, please drop us an
electric line.

Thanx

Farhad Anklesaria
[e-mail] Microcomputer and Workstation Systems Group
  [e-mail] University of Minnesota
   [e-mail] Minneapolis, MN 55455
    [e-mail]

So that's all the information I've managed to acquire so far. I'm
looking at writing to THINK to find out whether it's feasible to develop
a UN*X based InBox server (although it appears that Stanford have
already got there) in the same manner as the Aufs UN*X server. Another
option is to explore the new QUICKMAIL release from CE Software. Does
anyone know how to reach CE Software via electronic means?

My thanks to all of you who responded


--
Alex Heatley:                              Computing Services Centre
Domain: [e-mail]                Victoria University of Wellington
Path: ...!uunet!vuwcomp!alex               P.O Box 600, New Zealand
Trolls can often be found under bridges ... or in Computing Departments.

------------------------------

End of Usenet Mac Digest
************************
-------